IBIS Macromodel Task Group Meeting date: 04 January 2022 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma * Jared James Google: Zhiping Yang Intel: Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara * Ming Yan * Radek Biernacki * Rui Yang Todd Bermensolo Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the November 16th meeting. Radek moved to approve the minutes. Ambrish seconded the motion. There were no objections. ------------- New Discussion: Updated Agenda: Arpad noted that he had updated the Agenda in the ATM teleconference email: item 6 - List of topics for which we are awaiting updates item 7 - List of potential new topics suggested at previous meetings item 8 - List of issues from the Known Issues document for IBIS 7.1 that we may want to address item 9 - New potential issue with AMI clock forwarded models. BIRD213.1 draft 9: Walter moved to untable BIRD213.1. He noted that we had previously decided to table it until IBIS 7.1 was approved. Since IBIS 7.1 had been approved at the last Open Forum meeting, he had produced a draft 9 of BIRD213.1 that was written relative to IBIS 7.1. Bob seconded the motion. There were no objections. Walter reviewed draft 9. He said there were no substantive changes to the document. Change descriptions had been updated to reflect IBIS 7.1 page numbers. Changes that were redundant now that bit_time had been renamed symbol_time in IBIS 7.1 (BIRD214) were removed. Walter removed one additional change listed for page 229 that was redundant because of the symbol_time changes introduced in 7.1. Walter saved the resulting document as draft 10. Agenda item 9 - Possible issue with clock-forwarded AMI models: Arpad described the issue. He said for conventional SERDES models we allow the possibility that the Rx model will not return clock times. The EDA tool can apply its own CDR model to the signal, although even in this case it is not clear that the EDA tool's CDR model would behave the same way as the actual device. In the case of the new-to-IBIS-7.1 clock-forwarded Rx AMI data models, however, it really doesn't make sense to expect the EDA tool to derive clock times from the output data signal if the data model doesn't return clock times. In addition, the EDA tool may not be able to use the clock input to the Rx data model (which was output by the Rx clock model) because the Rx data model might be processing and modifying the clock times internally. Arpad suggested that we might want to require the Rx data model to return clock times. Walter agreed with Arpad's suggestion. He said any device being modeled this way probably has a clock tree and lots of other stuff in the path between the clock and the latch, and we only care about the clock at the latch. He said he had no objection to making the return of clock times mandatory for an Rx data executable model. He said that the model maker may simply return the input clock times if their model doesn't need to modify them. Arpad then asked if we should consider requiring all Rx models to return clock times. He said even for SERDES he never thought it was a great idea to make it optional. The EDA tool's CDR model might not be what the real CDR would do. Walter and Radek said such a change would violate the long-standing IBIS principle of older models being forward compatible (you can increase the version number on an older model and it should still work). Walter said it mirrored what had recently been done for statistical analysis, where the time to sample the latch is an optional Reserved Parameter Rx_Decision_Time (BIRD 205). Walter said he would not object to adding new language suggesting that model makers were "discouraged" from not returning clock times. Ambrish said similar language would need to be added for Rx_Decision_Time if we added it for clock_times. Agenda item 8 - IBIS 7.1 known issues: Issue 1 - Arpad said that the following sentence, which appears on pgs. 339 & 379 of IBIS 7.1 is grammatically incorrect: "If present under File_IBIS-ISS, Terminal_type A_gnd may be used any number of times on any of the terminal lines." He said the sentence implies that A_gnd may be used multiple times on the same terminal line. Walter agreed and suggested: "If present under File_IBIS-ISS, Terminal_type A_gnd may be used on any number of terminal lines." Bob agreed, and Bob, Walter and Arpad agreed this was a purely editorial fix that could simply be added to the IBIS 7.1 known issues document. Issue 2 - The [Pin] keyword does not include the "alphanumeric" restriction, which should be added for consistency with other pin name keywords. Arpad said that we should also explicitly define what we mean by "alphanumeric", and a strict definition would only include 0-9, a-z, A-Z. He noted that some new keywords that include the "alphanumeric" qualifier can themselves include [Pin] names, so [Pin] names could now implicitly have to be alphanumeric. Bob had tested the existing parser, and it did allow non-alphanumeric characters in [Pin] names while rejecting them in other pin name keywords (correct behavior according to the current specification). Walter said he wouldn't object to a definition of alphanumeric that included some special characters like '_' (underscore). Arpad agreed in principle, but said since pin names are limited to 5 characters the usefulness of a delimiter character like '_' is limited. He also noted Bob's argument that the original intent had been to support data book pin names, and the strict definition of alphanumeric was intended. Bob said if we assume the strict definition of alphanumeric, then this could just be an editorial change, as the original intent was for [Pin] names to be alphanumeric. Arpad said he thought he should draft a BIRD for this. Walter said he would not object to limiting [Pin] names to strict alphanumeric. He quickly searched and confirmed that all existing occurrences of "alphanumeric" in the specification are related to pin names and would be compatible with the strict definition. Bob agreed with this. Arpad took an AR to draft a BIRD. Issue 3 - The EMD [Designator Pin List] does not allow signal_type 'NC', and it requires all pin names from referenced IBIS Components to be listed. Arpad said he thought the requirement that [Designator Pin List] include all pins of the referenced IBIS Component should be relaxed. He explained that if, for example, the same IBIS Component were included five times, then all pins would be included five times. Since we currently don't allow 'NC', the model maker would have to invent fictitious and unique signal_names for each of the pins that wasn't actually connected/supported in the EMD model. Arpad said his interpretation of what 'NC' would mean in a [Designator Pin List] is that the EMD model has nothing connecting to that IBIS Pin. So, if we relax the requirement that all pins need to be listed, then 'NC' wouldn't be needed. Walter said he would like to adopt both of Arpad's suggested changes. Arpad asked whether we should have two BIRDs, one for relaxing the requirement that all IBIS Pins are listed in [Designator Pin List], and one for allowing 'NC'. Arpad said they could be independent BIRDs. Radek said they are interdependent. If you decide not to allow 'NC', then you would not just relax the requirement that all pins be listed, you might instead require that only pins connected to the EMD model are listed. Walter moved that we draft BIRDs to relax the requirement that all pins be listed and allow 'NC' in EMD [Designator Pin List]. Radek seconded. There were no objections. Arpad took an AR to draft the BIRDs. Bob noted that the current scheme, which requires all pins to be listed, allows the parser to crosscheck the EMD model against the referenced IBIS [Components]. - Walter: Motion to adjourn. - Jared: Second. - Arpad: Thank you all for joining. AR: Arpad to draft a BIRD clarifying "alphanumeric" in [Pin] names. AR: Arpad to draft a BIRD relaxing the requirement that all pins be listed in the EMD [Designator Pin List]. AR: Arpad to draft a BIRD allowing 'NC' signal_type in [Designator Pin List]. ------------- Next meeting: 11 January 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives